Performance Monitoring Indicators Help Optimize Resource Utilization Of Us High-defense Server 100g

1.

why should we perform performance monitoring on us high-defense 100g servers?

- protective servers still need to use resources efficiently under heavy ddos traffic to avoid waste or crashes.
- monitoring can identify problems such as link congestion, cpu saturation, memory leaks, and socket exhaustion in advance.
- when connecting cdn and domain name resolution (dns), you need to understand the impact of return-to-origin and cache hit rates.
- reasonably set thresholds (such as cpu 85%, number of incoming connections >200k) can trigger automatic expansion or current limiting.
- monitor historical data for capacity planning to reduce the risk of excessive investment in purchasing high-defense ports.

2.

key performance indicators (kpis) and their threshold recommendations

- bandwidth utilization: it is recommended that the 95/100g link full alarm threshold is 80% (ie 80 gbps).
- packet rate (pps): the maximum pps capability of the device, for example, the peak value of 100g protection equipment is 40 million pps, and the threshold is set to 70% (28 million pps).
- number of concurrent connections: the soft threshold is set to 200k and the hard threshold is 300k for http long connection scenarios.
- cpu and io: cpu usage alarms at 85%. if iowait exceeds 20%, please pay attention to the disk or network driver.
- syn semi-connection and abnormal packet ratio: if the syn ratio exceeds 5% of the total packets, syn cookies or rate limiting policy must be enabled.

3.

monitoring tools and indicator collection methods

- use prometheus+grafana to collect host indicators, application indicators and firewall/protection device data.
- netflow/sflow is used for link traffic sampling, calculating source ip distribution and top-n attack traffic.
- use tcpdump or pcap to perform deep packet inspection at low sampling volume (only for attack evidence collection).
- snmp or manufacturer api reads the pps and session table size of the protection device.
- log aggregation (elk/efk) is used to analyze request distribution, url popularity and cache hit rate.

4.

real case: a saas company’s optimization process after encountering ddos at its us node

- initial configuration: 100g high-defense port, protection device model x, 64-core cpu, 256gb memory, 10x10g direct-connect switching.
- attack performance: peak traffic 92 gbps, pps 30,000,000, causing session table overflow and service timeout in a short period of time.
- through monitoring, it was found that syn accounted for 12%, the single-source ip pps peak value was 50k, and the cache hit rate was less than 40%.
- optimization actions: enable syn cookies, implement rate limiting based on source ip on the protection side, deploy regional cdn back-to-origin buffering and increase cache ttl.
- optimization results: after traffic cleaning, the effective bandwidth dropped to 12 gbps, the pps dropped to 4,200,000, the session table was stable, and the average response time dropped from 850ms to 120ms.

5.

configuration examples and data demonstrations (comparison table before and after optimization)

- the following table shows the comparison of key indicators of the same server before and after optimization, making it easier to visually judge the optimization effect.

index	before optimization	after optimization
peak bandwidth	92 gbps	12 gbps
peak pps	30,000,000	4,200,000
syn proportion	12%	1.8%
session table usage	95%	40%
average response delay	850ms	120 ms

- server configuration example: intel xeon 6248r x2 (48 cores in total), memory 256gb, ssd raid10 (4x2tb), switch supports 100g qsfp28.
- protection strategy: hardware cleaning + cloud cleaning redundancy, flow limiting based on source ip and country dimensions, and rate dispersion with dns anycast and cdn.

6.

implementation suggestions and continuous optimization steps

- it is recommended to establish an alarm matrix: traffic, pps, number of connections, cpu, iowait, cache hit rate, etc. all require alarms and linked operation and maintenance.
- regular drills: simulate different types of attacks (syn flood, udp flood, http get flood) and record indicator changes.
- cooperate with cdn and domain name resolution providers: configure intelligent back-to-origin and fallback strategies to reduce direct impact on the back-to-origin server.
- cost control: based on the historical 95th percentile traffic and peak pps, evaluate whether it is necessary to maintain the 100g port for a long time or use elastic high-defense package annual expansion on demand.
- continuous iteration: optimize the protection rule base, adjust thresholds and upgrade device firmware based on monitoring data to deal with new attack methods.